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(54) Transcient tunneling for dynamic home addressing on mobile hosts 



(57) Portable and/or mobile I P hosts desiring to con- 
nect to the Internet can dynamically acquire a home ad- 
dress and other configuration information through DH- 
CP when powering up in a foreign network. A two-stage 
configuration procedure is used. First, the mobile host 
uses the M-IP protocol to establish contact with an ad- 
dressing element, referred to as a bootstrapping agent, 
that is usually co-iocated with a M-IP Home Agent, and 
that allocates a temporary home address for the mobile 



host. The temporary address is used to create a tempo- 
rary tunnel. Second, this temporary tunnel is used as 
the communication vehicle over which standard DHCP / 
transactions take place. The present invention is thus / 
arranged to use a) M-IP as the signaling mechanism for; 
reaching the home network and dynamically allocating 
a temporary home address for the mobile host; and b) 
DHCP to allocate a permanent home address and. any 
other configuration state for the mobile host. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to port- 
able and/or mobile communications, and more particu- 
larly, to a method for enabling a portable and/or mobile 
host, using the Mobile Internet Protocol (M-IP) to dy- 
namically acquire a home address in a manner consist- 
ent with the Dynamic Host Configuration Protocol (DH- 
CP) when powering up in a foreign network. 

BACKGROUND OF THE INVENTION " 

[0002] As used in this disclosure, a host device, which 
may oe a laptop computer, a personal digital assistant 
(PDA), a digital cellular telephone, or any other device 
adapted to perform two-way communication of informa- 
tion using the now well known Internet Protocol (IP), is 
considered to be "portable" when the device can be 
moved from one location to another, and operate at ei- 
ther location. A portable device does not have to operate 
WHILE it is being moved. On the other hand, a device 
is considered to be -mobile" when it can not only operate 
in different locations, but it can also operate WHILE it is 
being moved from location to location. If a device is 
adapted for mobile operation, it is, by definition, porta- 
ble Accordingly, in the following description, the use of 
the term "mobile host" will include both situations where 
the host is mobile (being moved) as well as where the 
host is in an area served by a foreign network. 
[0003] Dynamic Host Configuration Protocol (DHCP) 
is the current dynamic addressing and configuration 
protocol in widespread use oh the Internet. See R. 
Droms , Dynamic Host Configuration Protocol, R FC2 1 3 1 
Draft Standard. March 1997. DHCP not only enables 
hosts to acquire addresses but also other configuration 
options associated with the access network (e.g. . net- 
mask for subnet, domain name servers, directory serv- 
ers, email servers, etc.) See S. Alexander and R. 
Droms, DHCP Options and BOOTP vendor Extensions, 
RFC2132 Draft Standard, March 1997. As emerging 
and future client applications increasingly rely on net- 
work services, the ability to dynamically configure these 
services through options becomes important. The DH- 
CP protocol is a popular tool for today's service provid- 
ers to manage their addressing needs. 
[0004] While DHCP was originally intended for use 
with fixed hosts, it was a natural candidate to support 
dynamic addressing in the context of a host that would 
be portable and/or mobile. Since DHCP was designed 
for fixed hosts, its use on mobile hosts presented a 
number of challenges. Many of DHCP's limitations in 
supporting host mobility have been well documented in 
the literature; although none of such efforts have fo- 
cused on dynamic home addressing which is the target 
of this invention. See, for example, Charles Perkins and 
Kevin Luo, Using DHCP with Computers that Move, 



Wireless Networks Journal, vol. 1, pp. 341-353, 1995; 
Jon-Olov Vatn and Gerald Maguire Jr., The effect of us- 
ing co-located care-of addresses on macro handover la- 
. tency, in Proceedings of Nordic Teletraffic Seminar, Au- 
5 gust 1998; Jon-Olov Vatn, Long random wait-times for 
getting a care-of aefdress are a danger to Mobile Multi- 
media, IEEE Intl. Workshop on Mobile Multimedia Com- 
munications, pp. 142-144, Nov. 1999; and A. McAuley, 
S. Das, S. Baba and Y. Shobatake, Dynamic Registra- 
10 tion and Configuration Protocol (DRCP), httpy/search. 
ietf.org/internet-drafts/draft-itsumo-drcp-00.txt , Octo- 
ber 1999. 

[0005] In an attempt to enable seamless mobility of a 
host device while retaining Internet connectivity, the Mo- 
bile IP protocol (M-IP), as described by Charles Perkins 
in IP Mobility Support, RFC 2002 Draft Standard, Octo- 
ber 1996, was developed. The prime goal of M-IP is to 
enable mobile hosts to get connected to the Internet and 
remain connected WHILE they move. This connectivity 
is preserved in a "transparent" manner, that. is, in such 
a way that it prevents the disruption of networked appli- 
cations running on the mobile host while it moves. To 
accomplish this goal, M-IP relies on the ability to config- 
ure the device's IP address to match that of the subnet 
onto which it is attached at any point in time, since hav- 
ing the correct address is needed to ensure that packets 
get routed to the host. 

[0006] In M-IP, a mobile host has a fixed home ad- 
dress and acquires an additional care-of address (COA) 
that is updated as the host changes its location, called 
a "point of attachment". M-IP allows two options regard- 
ing the placement of a COA agent, also called the For- 
eign Agent (FA); the agent may be present inside the 
network (for example, at the base station) or as a co- ' 
located care-of address (CCOA) at the mobile host./ 
While M-IP relies on the ability to configure the homd 
and care-of addresses, it does not dictate how they are 
to be obtained. 

[0007] In the early stages of M-IP design, portable 
and/or mobile hosts had fixed home- addresses that 
were statically configured. Recently, the trend has shift- 
ed to a dynamic home addressing model, where a con- 
figuration protocol, which could be DHCP or some other 
protocol, enables these hosts to dynamically acquire 
and install a home address on power-up. Dynamic home 
addressing enables efficient management of address- 
es, which is critical in supporting wide-area wireless da- 
ta users with millions of devices using the limited ad- 
dress space dictated by the IPv4 standard. It also pro- 
vides ease of configurability, by replacing the burden- 
some task of manually configuring hosts with a more ef- 
fective mechanism for address allocation. Note that the 
IPv6 standard removes address space limitations but it 
also stands to benefit from the configurability advantag- 
es awarded by dynamic addressing support. 
[0008] One problem, however, that has been over- 
looked is that dynamic home addressing required when 
mobile hosts power up in a foreign network is not spec- 
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ified in the M-IP standard. Specifically, mobile hosts that 
power up in a foreign network with no home address 
cannot contact addressing servers in their home net- 
work through the type of "broadcasting" contemplated 
by DHCP. An alternative arrangement is needed that 5 
works, is compatible with DHCP and M-IP, and is easy 
to implement. 

SUMMARY OF THE INVENTION 

10 

[0009] The present invention is a method called Tran- 
sient Tunneling (TT) that allows configuring of portable 
and/or mobile IP hosts desiring to connect to the Inter- 
net, whereby such hosts can dynamically acquire a 
home address through DHCP when powering up in a *5 
foreign network. The method comprises a two-stage 
configuration procedure: First, the mobile host uses the 
M-IP protocol to establish contact with an addressing 
element, referred to as a bootstrapping agent, that is 
usually co-located .with a M-IP Home Agent, and that 20 
allocates a temporary home address for the mobile host 
that is used to create a temporary tunnel; second, this 
temporary tunnel is used as the communication vehicle 
over which standard DHCP transactions take place. The 
present invention is thus arranged to use a) M-IP as the 25 
signaling mechanism for reaching the home network 
and triggering the acquisition of a temporary home ad- 
dress for the mobile host; and b) DHCP to allocate a 
permanent home address and any other configuration 
state for the mobile host. 30 
[0010] The method of the present invention advanta- 
geously enables the use of conventional broadcasting 
procedures to properly discover an addressing server 
in their home network, and does not require changes to 
protocol standards. Only minor changes must be made 35 
to server implementations. The invention is simple to im- 
plement, avoids the problems that plague its alterna- 
tives, and exhibits acceptable performance. In addition, 
it leverages the growing DHCP code-base, with respect 
to its embedded support for important and often neces- ~~40 
sary host configuration options beyond addressing. 
While being DHCP-based, the method is potentially 
useful to any dynamic home addressing protocol that 
relies on broadcasting for server discovery. 

45 

BRIEF DESCRIPTION OF THE DRAWING 

[0011] The present invention will be more fully appre- 
ciated from a consideration of the following Detailed De- 
scription, which should be read in light of the accompa- 50 
nying drawings in which: 

Fig. 1 is a block diagram illustrating the typical ar- 
rangement of home and foreign networks, showing 
the cooperation between a home agent (HA) 1 01 55 
and a bootstrapping agent arranged in accordance 
with the present invention; 
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Fig. 2 is a diagram illustrating the standard DHCP 
messages that are exchanged for a mobile host to 
acquire a home address when it powers up in its 
home network and has no knowledge of an unex- 
pired home address lease; 

Fig. 3 is a diagram illustrating the messages that 
are exchanged when a mobile host powers up in a 
foreign network, in accordance with the arrange- 
ment of the present invention; 

Fig. 4 is a flow diagram illustrating the registration 
process performed in a M-IP HA when arranged in 
accordance with the present invention to include a 
bootstrapping agent; and 

Fig. 5 is a flow diagram illustrating the de-registra- 
tion process performed in a M-IP HA arranged in 
accordance with the present invention to include a 
bootstrapping agent. . 

DETAILED DESCRIPTION 

[0012] Before proceeding to describe the present in- 
vention, it will be helpful to briefly review Mobile IP and 
DHCP techniques, which are described in connection 
with Fig. 1 . which is a higtnevel block diagram showing 
the typical arrangement of home and foreign networks. 
[0013] In a Mobile IP network there are two mobility 
agents: a home agent (HA) 101 and a foreign agent (FA) 
1031 Home agent 101 gives mobility support to hosts 
(such as mobile host 110) that belong to the same home 
. network 1 02, while FA 103 serves hosts that are visiting 
from a foreign (remote home) network 104. Each mobile / 
host must have a home address and must also acquire / 
a care~of address (COA) when attached to a foreign net-: 
work. The manner in which the COA is assigned de- 
pends on whether the FA resides on the host, i.e., the . 
co-located orCCOA option, or on a device in the local 
access network. When an external FA is used, the COA 
becomes the address of one of its network interfaces. 
In the case of co-location, the host acquires a CCOA 
through static means or preferably through a dynamic 
addressing protocol like DHCP. The mobile host engag- 
es in two-way communication with a remote party, that 
shown in Fig. 1 as a corresponding host 130. In the de- 
scription below, unless otherwise stated, we assume 
that the CCOA option of M-IP is used, because it is the 
more general of the two options. Most of the description 
below will apply to the network-based COA option as 
well. Where there are differences between the network- 
based (COA) option and the host based (CCOA) option, 
they are described below. 

[001 4] Packets sent to the mobile host 110 from a re- 
mote sender such as corresponding host 130 are al- 
ways addressed to its home address. While the host is 
attached to its home network 101 , packets reach it fol- 
lowing conventional routing via the Internet 120. When 
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the host moves into a foreign network 104, it acquires a 
COA and registers it with its home agent 1 01 . Once reg- 
istered, packets destined to its home address are routed 
as normal packets until they reach the home network 

102, where the home agent 101 intercepts them. The 
home agent 1 01 encapsulates these packets to address 
them to the host's COA. Encapsulated packets are then 
routed as usual until they reach the host's foreign agent 

103. These tunneled packets, transmitted through Inter- 
net 120 via a path that is often described as a tunnel 
(labeled 122 in Fig. 1) -are decapsulated (i.e., the COA 
is removed) by the foreign agent 103, and the original 
packet is forwarded to the mobile host 110. For details 
on "IP tunneling", see "IP Encapsulation within IP", 
Charles Perkins, RFC 2003 Draft Standard, Oct. 1996. 
In the reverse direction, packets sent from the host 110 
to corresponding host 130 (the remote party engaged 
in the call session), may optionally be reverse-tunneled, 
that is, encapsulated by the FA 1 03 and sent back to the 
home agent 101, which decapsulates and forwards 
them to the remote party. Each timeThe host 110 moves 
between points of attachment crossing a network or 
subnet boundary, it acquires a new care-of address and 
re-registers it with its home agent. Homo agents asso- 
ciate a lifetime to the state they install for a host, requir- 
ing periodic lifetime renewals to avoid state expiration 
and removal. 

[0015] Let us now turn our attention to DHCP. DHCP 
has a client-server architecture, in which a DHCP server 
150 in Fig. 1 is accessible to a client on a mobile host 
via intranet 160, when the mobile host powers up in 
home network 102. A server manages a portion of the 
IP address space on a network by disbursing addresses 
and other configuration parameters to clients, such as 
name server addresses, on a request basis. A client run- 
ning on a host allows it to dynamically acquire configu- 
ration state, replacing conventional static methods re- 
quiring manual intervention. If there are no servers on 
the same subnet to which the host is connected, a relay 
is introduced for forwarding client requests to servers 
on othersubnets. Configuration parameters acquired by 
a client are leased, i.e., they have an associated expi- 
ration time, requiring periodic lease renewals to prevent 
lease expiration and configuration state removal. 
[0016] Client-server communication takes place in 
the following manner. Packets destined to the server are 
always sent as IP broadcasts when the client does not 
know the address of a server. Otherwise, it may unicast 
its requests to the server's IP address (e.g., during a 
lease renewal). Packets destined to the client are usu- 
ally sent as IP broadcasts, with two exceptions. First, if 
the client's request was forwarded from a relay, the serv- 
er unicasts its response to the relay's IP address. The 
relay, in turn, broadcasts the packet on its subnet in or- 
der to reach the client. And second, if a particular flag 
in the DHCP packet header called the broadcast bit "B" 
bit is cleared, the server unicasts its replies to the client's 
hardware address, with the offered IP address in the 



destination field of the IP header. These rules have im- 
portant implications for configuring a remote client. 
[0017] In order to better understand the broadcasting 
problem that currently prevents a mobile host powering 

5 up remotely from using DHCP to dynamically acquire a 
home address needed to connect to the Internet, con- 
sider the following model: A mobile host relies on DHCP 
to dynamically configure both its home address and its 
co-located COA. This implies that clients running on the 

10 host must acquire and maintain leases on both address- 
es. Let us refer to the clients for the home address and 
for the CCOA as Hclient and Fclient, respectively. 
[0018] Assume a mobile host powers up in its home 
network with no knowledge of an unexpired home ad- 

15 dress lease. Since it needs to acquire one, it initiates 
the execution of Hclient, which must go through a full 
initialization (rather than a speedier reboot). Fig. 2 is a 
diagram that illustrates the standard addressing mes- 
sages that are exchanged. Hclient attempts to contact 

20 a server by broadcasting a DISCOVER message (illus- 
trated as rightward arrow 201 in Fig. 2 that originates 
from the mobile host) on its local subnet. This is actually 
a limited broadcast message since it is destined to ad- 
dress 255.255.255.255. The message is received by a 

25 server, or a relay on that subnet that is configured'to 
forward the message (illustrated as rightward arrow 202 
in Fig. 2) to a home DHCP server elsewhere on the 
home network (the scenario shown in Fig. 2 includes a 
home DHCP relay). When the message 202 reaches the 

30 server, it responds with an OFFER message (illustrated 
as leftward arrows 203 and 204 in Fig, 2) that it either 
broadcasts on its subnet or unicasts to the relay that had 
forwarded it. Whether through the relay or directly from 
the server, the mobile host receives the message 203,/ 

35 204 as a limited broadcast. Hclient then broadcasts a 
REQUEST message (illustrated as rightward arrows 
205 and 206 in Fig. 2), reaching the server directly or 
via the relay, as before. The server responds with an 
ACK message (illustrated as leftward arrows 207 and 

40 208 in Fig. 2), confirming the granting of a lease. The 
ACK message 207, 208 reaches the host once again as 
a limited broadcast and Hclient concludes its lease ac- 
quisition by installing acquired state on the host's inter- 
face. Though not shown in Fig. 2, Hclient periodically 

45 enters the lease maintenance stage where it sends re- 
newals to its home server. As per the M-IP standard, no 
M-IP registrations are needed while the host is in its 
home network. 

[0019] Now let us consider the case where a host 
50 powers up in a foreign network. Once again, assume, 
without loss of generality, that the host holds no unex- 
pired home address leases. If Hclient attempts to send 
a limited broadcast message in the hope of contacting 
a server that can grant it a home address, it will fail. Any 
55 upstream broadcast messages will be received by a lo- 
cal server or relay which may offer an address from its 
own lease pool, not that of the host's home network. 
Hclient needs a way to contact its remote home server, 
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as standard broadcasting procedures will not enable a 
proper server discovery. 

[0020] In brief, standard DHCP broadcasting proce- 
dures do not work for dynamic home addressing on mo- 
bile hosts that power up in a foreign network. Messages 5 
sent by a host client cannot reach a remote home server 
to acquire or renew a home address lease. 
[0021] In order to bridge the gap between a mobile 
host powering up in a foreign network and its remote 
home DHCP server, the present invention uses the no- 10 
tion of an addressing agent, shown in Fig. 1 as a boot- 
strapping agent 140, for temporary home address allo- 
cation coupled with the assistance of M-l P. Basically, the 
present invention is arranged to use a) M-IP as the sig- 
naling mechanism for reaching the home network and 15 
triggering the acquisition of a temporary home address; 
b) a bootstrapping agent 140 cooperating with HA 101 
in the home network to allocate a temporary home ad- 
dress for the host; and c) DHCP to allocate a permanent 
home address and any other configuration state for the 20 
host. Variations in the design of the addressing agent 
and its interaction with M-IP and DHCP are possible, 
and are discussed in detail below. 
[0022] On power-up, the host must first determine 
whether it. is in its home or in a foreign network. This 25 
location determination may be based on knowledge of 
its NAI, such as a user email address 1 . For example, a 
M-IP client on the host may listen for periodic advertise- 
ments from a home or foreign agent containing the do- 
main name which it can then compare against its own 30 
NAI. If the host is in its home network, the process de- 
scribed above in connection with Fig. 2 is used. If the 
host is in a foreign network, the present invention is in- 
voked, using the message flows illustrated in Fig. 3. 
[0023] As shown in Fig..3, the host first needs to ac- 35 
quire a co-located COA, so it spawns a DHCP client 
(Fclient). In accordance with standard M-IP processing, 
a DISCOVER message (illustrated as rightward arrows 
301 and 302 in Fig. 3) is sent from the mobile host (MH 
in Fig. 3) to the foreign DHCP server, via a foreign DHCP 40 
. relay. In response, an acknowledgement (ACK) mes- 
sage (illustrated as leftward arrows 303 and 304 in Fig. 
3) is returned. Once the mobile host acquires the COA, 
it sends a unicast M-IP registration message (illustrated 
as rightward arrow 305 in Fig. 3) to Its HA. It is here 45 
assumed that the address of the HA is known to the mo- 
bile host through static configuration or some other 
me_ans such as dynamic home agent address resolu- 
tion. 2 See Charles Perkins, IP Mobility Support, RFC 
2002 Draft Standard, October 1996. The registration so 
message contains the host's COA and its NAI, but no 
home address. 

[0024] When the HA receives the registration mes- 
sage and notices that the home address is missing, it 

1 55 

1 A wireless link layer identifier such as the Mobile Identification 

Number (MIN) can be mapped to a NAI[10]. 

2 Dynamic home agent address resolution requires the mobile host to 
know the broadcast address for. its home subnet. 
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contacts bootstrapping agent 140 in Fig. 1 to acquire a 
temporary home address on behalf of the host. In one 
embodiment of our invention, bootstrapping agent 1 40 , 
which can be thought of as a "lightweight addressing 
agent", is placed on the M-IP HA. However, it is to be 
noted here that bootstrapping agent 140 can also be lo- 
cated remotely from HA 1 01 . In either event, bootstrap- 
ping agent 140 disburses temporary home addresses 
to_the mobile host. This address pool may contain pub- 
lic, globally routable IP addresses or private IP address- 
es in the class 10.*. Drawing from a pool of private ad- 
dresses is usually preferable when public addresses are 
scarce and must be used sparingly. Henceforth, we as- 
sume that the addressing pool consists of private ad- 
dresses, although the transient tunneling procedure ap- 
plies to either case. Once a 10.* address is assigned, 
the HA uses It to set up a tunnel to the COA of the host. 
The HA unicasts a registration reply message (illustrat- 
ed as leftward arrow 306 in Fig. 3) containing the 10.* 
address back to the host. On receipt, the host sets up 
its end of the tunnel. Then Hclient is initialized on the 
host and launches a standard set of transactions need- 
ed to acquire a home address and other configuration 
options through the transient tunnel (highlighted with 
bold arrows in Fig. 3). All Hclient messages must be re- 
verse tunneled through the HA to ensure that they are 
not received by any local DHCP servers or relays. Re- 
verse tunneled messages are forwarded on tha home 
subnet by the receiving HA, so that a home server or 
relay receives them. Similarly, replies sent by a home 
server or relay are tunneled to the remote host. Using 
this transient tunnel, Hclient can acquire an address 
(and other requested configuration state) from a home 
server without concerns about broadcasting. f 
[0025] The message flow in Fig. 3 in which the home / 
address is acquired includes transmission of a DHCP: 
request message 307 from Hclient to the HA 1 01 in Fig. 
1, using tunneling; the extra address is stripped off at 
the HA, and the DHCP request message 307a is trans- 
mitted from the HA to the home DHCP server 1 50 in Fig. 
1 via intranet 160. In the return direction, the address 
information is sent from the DHCP server to the HA in 
message 308a; at the HA, the extra address is added, 
and the message 308, including the desired address in- 
formation, is transmitted to Hclient on mobile host 110 
in Fig. 1 using tunnel 122 in Fig. 1. 
[0026] After this bootstrapping phase, the 10. * ad- 
dress should be released 3 , and its associated tunnel 
torn down and replaced with a tunnel terminating at the 
DHCP-granted permanent home address. This is ac- 
complished by sending a M-IP de-registration message 

309 from the host to the HA. An M-IP reply message 

310 is then returned to the mobile host. Note that the 
Mobile IP tunnel associated with the 10.* address can 
also be allowed to time-out, instead of requiring the mo- 
bile host to send an explicit de-registration message 

3 Alternatively, the 10." address could have a short lease (In the order 
of 10 seconds) and be allowed to time-out. 
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(309) and wait for a reply (31 0). 
[0027] Once the permanent home address is known 
to the mobile, a registration containing address can oc- 
cur. This involves sending a message 311 with a perma- 
nent home address from the M-IP client to the HA, and 
receipt of an M-lP reply message 312 in return. Note 
that lease renewals may also be broadcast, since they 
are reverse-tunneled to the home network. 
[0028] For this process just described to work, the 
broadcast bit options in DHCP and M-IP must be set. 
The broadcast "B" bit in the flags field of DHCP query 
messages must be set by the clients to ensure that the 
replies from the server or relay in the home network 
reach the client on the host while it is in the foreign net- 
.work. Existing implementations of DHCP clients, such 
as on Microsoft Windows and JSC's implementation for 
UNIX always set the broadcast bit by default. By setting 
this bit, the client informs the server or relay to send any 
replies to the host as a broadcast using an IP broadcast 
address as the IP destination address and the link-layer 
broadcast address as the link-layer destination address. 
This ensures that the HA receives broadcast packets for 
subsequent forwarding to the host. The M-IP broadcast 
n B M bit in registration requests must also be set to ensure 
that the HA tunnels broadcast messages back to the 
host. A drawback in setting this bit is that the host may 
receive a flood of unwanted broadcast messages from 
its home network that are forwarded by its HA This 
would result in a significant waste of wireless bandwidth. 
Strategies to address this issue are discussed below. 
[0029] To summarize, transient tunneling as imple- 
mented in accordance with the present invention uses 
a bootstrapping addressing agent on the home agent to 
allocate private home addresses. This enables a tem- 
porary tunnel to be established to the host over which a 
standard, co-located DHCP client can acquire a lease 
from a pool of public (i.e., globally routable) home ad- 
dresses. Once a home address is acquired, it is used to 
replace the temporary tunnel with a corresponding M- 
IP tunnel. 

[0030] Note again here that the present invention is 
not needed for hosts powering up in their home network. 
However, power-ups in a foreign network, where it is ap- 
plicable, are expected to be the more frequent case (e. 
g., use of M-IP for corporate access). 
[0031] A flow diagram illustrating the registration 
process performed in HA 101 of Fig. 1 arranged in ac- 
cordance with the present invention to work coopera- 
tively with a bootstrapping agent 140, is shown in Fig. 
4. The process is initiated in step 401 , when a registra- 
tion message (message 305 of Fig. 3) is received at HA 
101 (Fig. 1) from MH 110 (Fig. 1). A determination is 
made in step 403 as to whethefthe. registration mes- 
sage specifies a home address. This might occur for 
example, if the mobile host 110 had already been pro- 
vided with a static home address. If so, a YES result 
occurs, and the process proceeds to step 405, in which 
a standard registration procedure is performed. 



[0032] If a NO result occurs in step 403, the process 
continues to step 407 to determine if the registration re- 
quest includes a network access indicator (NAI). If not, 
a NO result occurs, and the process terminates in step 
5 406, in which" a error code is returned to MH 110 using 
the M-IP protocol. If an NAI is present, authentication 
procedures are initiated in step 409, and the process 
determines, in step 41 1 , if authentication was.successf ul 
for the NAI determined to be present in step 407. If not, 
10 a YES result occurs in step 411, and the process again 
— proceeds to step 406. If authentication occurs, boot- 
strapping agent 140 (Fig. 1 ) is used, in step 41 3 : to tem- 
porarily allocate a 10.* address to MH 110. A determi- 
nation of the success of the allocation process is made 
is in step 41 5. If the process fails (for any possible reason), 
a YES result occurs in step 415, and the process termi- 
nates with step 406. Otherwise, a NO result occurs in 
step 415, and a tunneling entry (using the 10.* address 
as a COA) is then set up at HA 101 in step 417. The 
registration process is complete when HA 101 returns 
a registration reply (message 306 of Fig. 3) to MH 110 
using the COA, and including the 10.* address. 
[0033] A flow diagram illustrating the de -registration 
process performed in HA 1 01 (Fig. 1 ) together with boot- 
strapping agent 1 40 (Fig. 1 ) is shown in Fig. 5. The proc- 
ess is initiated in step 501 , when a de-registration mes- 
sage (message 309 of Fig". 3) is received from MH 110 
in HA 1 01 . This message triggers an authentication pro- 
cedure in step 503. If it is determined in step 505 that 
the authentication failed, a YES result occurs, and a er- 
ror code message is sent to the MH using the M-IP pro- 
tocol. If the authentication is successful, the process 
continues to step 509, in which a determination is made 
as to whether the de-registration relates to an address/ 
in the 1 0.* format. If not, a NO result occurs in step 509,' 
and the conventional or standard de-registration proce- 
dure is performed in step 511 . Alternatively, if the result 
of step 509 is YES, the tunnel previously established in 
step 417 of Fig. 4 is torn down in step 513, and in step 
515 bootstrapping agent 140 releases for re-use the 
10.* address allocated in step 413 of Fig; 4. A reply 
(message 310 in Fig. 3) is sent from HA 101 (Fig. 1) to 
MH 110 in step 517, indicating that the de-registration 
process has been completed. 

[0034] The present invention can be modified, If de- 
sired, to make more efficient use of wireless bandwidth. 
This modification is practical and useful, since mobile 
hosts usually connect to an IP access network through 
a wireless air link, where bandwidth tends to be limited 
and costly due to physical and regulatory constraints. 
As a result, practical mobility solutions should be con- 
cerned with the effective use of air bandwidth. Typical 
approaches to address this concern are packet com- 
pression techniques and the reduction of over-the-air 
traffic. We focus on the latter approach. 
[0035] Traffic over-the-air may be reduced through 
the prevention of bandwidth waste. One way to prevent 
bandwidth waste in the transient tunneling process of 
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the present invention is to stop unwanted broadcast 
packets originating in the home network from being tun- 
neled to the mobile host by its HA. Recall from previous 
description that a broadcasting bit needs to be set in the 
HA so that DHCP packets broadcast by a server or relay 
in the home network reach the host in a foreign network. 
Unfortunately, all broadcast packets will be forwarded 
when the transient tunnel is present, not just the few de- 
sired DHCP packets. This introduces a costly traffic bur- 
den, especially over low bit-rate wireless links. We now 
describe an approach to eliminates this undesirable 
broadcast traffic overhead. 

[0036] In the "co-located relay" approach, the DHCP 
client is modified to mimic the operation of a joint client 
and relay. By sending messages to the server as if they 
were passing through a relay, the server is tricked into 
responding with IP unicast messages, thus eliminating 
the need for the HA to forward any broadcast packets 
downstream. The co-located relay (i.e., the relay at the 
mobile host) is arranged to use the private (temporary) 
home address of the host acquired through transient 
tunneling process of Fig. 4 as its IP address, and adver- 
tise it to the home DHCP server in the 'giaddr 1 field of 
messages 307 and 307a of Fig. 3. It should be noted 
that address assignment rules used by the DHCP server 
to decide which address to assign to an incoming re- 
quest are not standardized. Server implementations of- 
ten select an address on the subnet where the relay re- 
sides, if the request was relayed, or on the subnet as- 
sociated with the server's interface on which the request 
was received. This may result in an undesirable address 
assignment for transient tunneling, entailing possible 
implementation-dependent changes to the server's sub- 
net selection rules. When the DHCP server receives the 
DHCP request (message 307a of Fig. 3), and notices 
that the 'giaddr* field is populated, it responds with a uni- 
cast message (message 308a in Fig, 3) destined to the 
private home address specified in the 'giaddr* field. This 
message is intercepted by the HA, and tunneled to the 
COA using the tunnel set up using the process of Fig. 
4. When the mobile host receives the DHCP reply (mes- 
sage 308 of Fig. 3) it is processed through this virtual 
relay to eliminate relay state (i.e., clear 'giaddr* field) and 
hand it off to the client for normal processing. This ap- 
proach to bandwidth conservation hinges on the fact 
that transient tunneling assigns a private (temporary) 
home address thai can be used to simulate DHCP relay 
functionality for acquiring the home address. A short- 
coming of this approach is that it requires a server to be 
on the same subnet as the HA, because a relayed DH- 
CP request cannot go through more than one relay on 
its way to a server. 

[0037] As indicated previously, the description of the 
transient tunneling process assumed that the FA is co- 
located with the mobile host. However, in some instanc- 
es, it is necessary or desirable to use an external foreign 
agent. If this is. done, the transient tunneling process 
shown in Fig. 3 is slightly different. First, the mobile host 
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acquires .a COA from an external foreign agent, rather 
than from a DHCP server as shown in messages 301 
through 304. Second, the mobile IP registration mes- 
sage is sent by the client on the mobile host to the ex- 

5 ternal foreign agent (not directly to the home agent, as 
shown by message 305 in Fig. 3). The externa! foreign 
agent forwards the registration message to the HA In 
the reverse direction, the HA replies to the external for- 
eign agent with the 1 0.* home address, which is used 

10 by the external foreign agent to set up its end of the tran- 
sient tunnel. Thus, a third difference in this arrangement 
is that, unlike what is shown in Fig. 3, the transient tunnel 
extends between the external foreign agent (not the mo- 
bile host) and the HA. After the transient tunnel is set 

'5 up, the foreign agent forwards the registration reply 
message to the client on the mobile host. Finally, it is to 
be noted that when an external foreign agent is used, 
the de-registration process shown in Fig. 3 is also slight- 
ly different, in a manner ^similar to that just described. 

20 [0038] The use of private home addressing with M-IP 
raises the possibility of host address collisions at the ex- 
ternal foreign agent. Since by definition private address- 
es are not globally unique, it is possible than an overlap 
occurs between the private addresses of hosts belong- 

25 ing to different HAs but served by the same FA. To re- 
solve such addressing conflicts and ensure proper rout- 
ing to the hosts, the FA can use additional host config- 
uration state, such as the HA address. Persons skilled 
in the art will have various available mechanisms for re- 

30 solving these addressing conflicts. 



Claims 

t 

i 

35 1. A method for configuring a portable and/or mobile / 
host that powers up in a foreign network to connect; 
to the Internet, comprising the steps of 

creating a bootstrapping agent that works co- 
40 operatively with a M-IP home agent to allocate 

a temporary home address to said portable 
and/or mobile host, 

using the M-IP protocol to contact said M-IP 
home agent and request said bootstrapping - 

45 agent to allocate said temporary home address 

to said portable and/or mobile host, and 
using said temporary home address to create 
a temporary tunnel between a foreign agent as- 
sociated with said portable and/or mobile host 

50 and said M-IP home agejit, wherein said tem- 

porary tunnel is used to communicate configu- 
ration information including a permanent home 
address allocated by the DHCP protocol for 
said portable and/or mobile host to connect to 

55 the Internet. 

2. The method of claim I wherein said foreign agent is 
co-located with said mobile host. 
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3. The method of claim I wherein said foreign agent is 
located on a device that is external to said mobile 
host and resides in said foreign network. 

4. The method of claim 1 wherein said bootstrapping 5 
agent is arranged to assign IP addresses from an 
address pool of private addresses. 

5. The method of claim 4 wherein private addresses 
are in the format 10.*. 10 



6. The method of claim 1 wherein said bootstrapping 
agent is arranged to assign IP addresses from an 
address pool of public addresses. 

7. The method of claim 1 wherein a DHCP client lo- 
cated on said portable and/or mobile host Is used 
to generate messages requesting said configura- 
tion information from a DHCP server via said tem- 
porary tunnel. 

8. The method of claim 7 wherein said messages gen- 
erated by said DHCP client are modified at said 
portable and/or mobile host to have a format con- 
sistent with a DHCP relay. 

9. A method for enabling a mobile host without an IP 
home address to connect to the Internet when pow- 
ering up in a foreign network, comprising the steps 
of 

obtaining a temporary I P home address for said 
mobile host from an IP address source acces- 
sible through a mobile IP home agent, 
establishing a. transient tunnel between said 
mobile IP home agent and a mobile IP foreign 
agent associated with said mobile host while in 
said foreign network, using said temporary IP 
home address, 

acquiring, via said transient tunnel, configura- 
tion parameters including a permanent IP home 
address from a DHCP server in the home net- 
work of said mobile host, 
replacing said transient tunnel with a new tun- 
. nel between said mobile IP home agent and 
said mobile IP foreign agent using said perma- 
nent IP home address. 

10. A method for enabling configuration of a portable 
host device that powers up in a foreign network to 
communicate using the Internet, said method com- 
prising the steps of 

communicating a temporary home address to 
said portable host device from a bootstrapping 
agent operating cooperatively with a mobile IP 
home agent that serves said portable host de- 
vice when it operates in said foreign network, 



establishing a transient bidirectional communi- 
. cation link between said portable host device 
and said mobile IP home agent using the M-IP 
protocol and said temporary home address, 
and 

obtaining a permanent address from a DHCP 
server via said transient bidirectional commu- 
nication link, wherein said permanent address 
is used thereafter to configure said portable 
host to communicate with the Internet. 

11. The method defined in claim 10 wherein additional 
configuration parameters are provided to said port- 
able host device via said transient bidirectional 

15 communication link. 

12. In a mobile telecommunications system in which a 
portable and/or mobile host device can operate In 
a home network that includes a home agent or in a 

20 foreign network that includes a foreign agent, a 
method for configuring said portable and/or mobile 
host when it powers up in said foreign network, said 
method comprising the steps of 

25 using the M-IP protocol in said portable and/or 

mobile host as the signaling mechanism for 
reaching said home network and dynamically 
allocating a temporary home address; and 
thereafter using DHCP with the temporary 
30 home address to allocate a permanent home 

address and other configuration state for said 
portable and/or mobile host. 

13. A method for configuring a mobile host that powers/ 
35 up in a foreign network, comprising the steps of / 

setting up a temporary IP tunnel via the Mobile 
IP protocol to connect said mobile host to its 
home network, 

40 using an IP broadcasting protocol over said 

temporary IP tunnel so that said mobile host 
can discover a DHCP. addressing server in its 
home network, and 

using the DHCP protocol to communicate ad- 
45 dressing and configuration information be- 

tween said addressing server and said mobile 
host. 

14. In a system arranged to use an IP tunnel to relay 
50 via the internet communication packets that are 

destined to a mobile host from a home server in said 
host's home network to a foreign server when said 
host is in a foreign network, wherein the establish- 
ment of said IP tunnel requires said home server 
55 and foreign server to know the IP home address of 
said mobile host, a method for configuring said mo- 
bile host when it powers up in said foreign network 
without said IP home address, comprising the steps 
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of 

obtaining a temporary IP home address for said 
mobile host from an IP address source acces- 
sible through said home server, 
establishing a transient tunnel between said 
home server and said foreign server using said 
temporary IP home address, 
acquiring, via said transient tunnel, permanent 
configuration parameters including a perma- 
nent IP home address from a DHCP server in 
the region served by said home server, 
replacing said transient tunnel with a new tun- 
nel between said home server and said foreign 
server using said permanent IP home address. 
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FIG. 2 

PROCEDURE FOR MOBILE HOST POWER-UP AT ITS HOME NETWORK 
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FIG, 4 

M-IP HA WITH A BOOTSTRAPPING AGENT REGISTRATION PROCEDURES 
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FIG. 5 

DE-REGISTRATION PROCEDURES 
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